A number of proposed solutions have been advanced to address the problem of effecting the communication of data between computer system platforms and applications developed using distinctly different technologies. The increased reliance on distributed data processing systems and architectures, such as those employed to support Internet and Electronic Data Interchange (EDI) activities for example, has created a keenly felt need for an improved approach to designing and deploying an integrated information system capable of transporting vast amounts of data of various types and formats between applications having dissimilar interface characteristics.
In an attempt to address the problem of transporting dissimilar types of data between dissimilar systems and applications, various data interchange products and approaches have been developed. A traditional approach of electronically linking a number of disparate systems together involves the creation of custom gateways or interface systems. A typical custom gateway is created to solve a narrowly focused interface problem, such as permitting systems #1 and #2 to exchange data of types `A` and `B` produced by systems #1 and #2, respectively. Such specialized gateways are generally not intended nor designed to accommodate data interchange between a large number of disparate systems and applications. It is understood in the art that modifying an existing custom gateway to address a new and different interface problem is generally unproductive and costly, given the inherent limitations of the original gateway design.
Various information technology standards have been advanced in an attempt to address these and other data interchange problems experienced within a distributed data processing and communications environment. One such standard, referred to in the art as CORBA (Common Object Request Broker), has received much recent attention, as it would appear to solve many of the aforementioned problems. A critical review of the CORBA approach, however, reveals that CORBA is not designed to act as a data transport mechanism. Rather, CORBA is primarily designed to pass control methods over TCP/IP. The strength of CORBA is its ability to use C++ methods over a network. CORBA requires that all applications must be object oriented, which precludes inclusion of a substantial number of existing applications developed using structured programming techniques. Moreover, although CORBA is referred to as a "standard,` there are several product implementations of CORBA which are not compatible, and as such, are incapable of communicating with one another.
Other technologies, such as transaction monitors, have been developed primarily to control complex transactions between multiple applications in a distributed processing environment. Such transaction monitors typically interface applications through rigorous transaction rules applied through defined IDL (Interface Definition Language) interfaces across IPC (Inter Process Communication) methods. A typical transaction monitor has a complex structure that must be conformed to, and is complicated to use and maintain. If any one of the individual transactions that make up a transaction set fails, the entire complex transaction must be backed out, rather than the single failed transaction. Transaction monitors are generally optimized for transaction control, and not for effecting data interchange.
Fourth and fifth generation languages, termed 4GL and 5GL, would appear to offer a partial solution to the data interchange problem. These and other similar languages, such as those used to construct "business objects," are optimized around the construction of applications and user interfaces for the primary purpose of providing powerful querying and reporting tools. The objects created by such languages typically define access paths to data residing in databases. The objects can be combined in various ways to create complex queries and for building powerful report generators. Fourth and fifth generation languages are not well suited for transporting vast amounts of data from one application to one or more other applications in a reliable and efficient manner. Although business objects constructed using 4GL and 5GL techniques do carry with them a certain amount of data, this data is typically data resulting from a query that is transported with an object definition for the purpose of performing additional analysis on the data.
Further complicating the technical problems associated with prior art data integration approaches is the recognition that disparate information sources are typically integrated to serve business needs and objectives. A proposed technical solution to a data integration problem should not inhibit a user's ability to obtain meaningful information derivable from the data passing through the proposed system. On the contrary, a proposed technical solution should meet or exceed the user's business information needs, and furthermore, should provide an extensible framework capable of readily accommodating new information sources and technologies.
Conventional data integration tools are typically designed to reduce the effort and cost expended on integrating dissimilar information systems from a technical perspective, but are generally employed with little or no regard given to the potential limiting impact the resultant solution may have on business information requirements. Business level integration is typically accomplished using tools very different from those employed to effect data integration. Moreover, the runtime environment of a conventional data integration deployment is typically maintained through use of separate set of system administration tools.
Incompatibilities of varying severity often arise in systems in which the technical integration solution rests on a foundation or framework different from that supporting the business integration solution. Such incompatibilities generally limit the user's ability to efficiently interact with a conventionally implemented integrated information system during the design and deployment phases, and significantly complicates the effort of extracting meaningful system and business integration/management information from the system.
There exists a keenly felt need for an improved data integration system and methodology capable of effectively integrating data produced by applications of varying technologies. There exists a further need for such a system and methodology that employs a single intuitive user interface that provides various types of information to users having disparate data input and output requirements. There exists yet a further need for such a system and methodology that is readily extensible and is independent of any current or future technology. The present invention fulfills these and other needs.